perm filename HIGHER[S79,JMC] blob
sn#441365 filedate 1979-05-17 generic text, type C, neo UTF8
COMMENT ā VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 Notes on higher level programming or specification languages
C00007 ENDMK
Cā;
Notes on higher level programming or specification languages
When one specificies in English what one would like a computer
to do, what is stated is often far from a present day computer
program in any known programming language. It might be supposed
that the difference has to do with the vagueness of natural
language, and maybe some of it does. However, there seem to
be ways of mathematically putting specifications on a program
that correspond to English usage, are entirely precise, but
are not allowed by present languages.
We need to specify what the program is to know and what it is to
do. The most obvious (to a programmer) way of specifying what
is known is by means of data structures, but specifying data
structures may already require that a substantial part of the
work of programming be done. One weaker specification was
given in the Elephant reservation program, and it could be
reformulated as specifying that the program knows who has
a reservation. One might only later specify that a passenger has
a reservation if he
made one successfully and hasn't cancelled it.
Another example from the blocks world would be to say that
the program knows what blocks can be placed on what other blocks
without ourselves specifying yet what these rules are. We could
even imagine that the program has to obtain these rules by
experiment or by asking someone other than ourselves.
If we take the image of a general or a company president or
even a professor saying what he wants the computer to do, we
see that this official can be precise in saying what he wants
accomplished without supplying all the knowledge required to
accomplish it.
Here is an idea that may help. We can draw boundaries around
parts of a computer system. For example, the CPU knows the program
counter and the contents of the registers. From its point of
view, the program is external data which it manipulates. From the
point of view of the interpreter, the interpreter code is part of
itself, but the Lisp program is data. From the point of view of
the Lisp program certain of the list structures and arrays are
part of itself, i.e. knowledge, and other structures are external,
i.e. data. The boundaries are arbitary, but the applicability of
the concepts of knowledge and purpose may depend on drawing the
boundaries appropriately. The intuition is that it may be useful
to make these boundaries. When there are parallel processes the
situation gets even more complicated as several parts of the system
may have distinct knowledge sets and purposes.
Circumscription is in this picture at some point.